Out-of-order value-vs-table and dotted-key-vs-table redefinitions
were silently accepted (or only raised on access) because the inner
if-elif chain in Container.append had no else clause for the case
where an existing concrete table is extended by a super-table after
an unrelated table header.

Changes

• Add else clause in Container.append that validates the super-table
  against the concrete table, catching type mismatches and double table
  definitions at parse time instead of lazily during access/unwrap.
• Enhance _validate_table_candidate to detect when a non-dotted
  candidate key is a prefix of an existing dotted key.
• Call _validate_out_of_order_table after _raw_append in the
  fallthrough path so out-of-order fragments are validated immediately
  (previously this validation only ran in the super+super INSERT path).

Scenarios fixed

1. Value-then-table split — [a]\nb = true\n[zz]\nq = 9\n[a.b]\nc = 1\n
   (out-of-order) now raises ParseError at parse time.

2. Dotted-key-then-table split — [a]\nb.c = 1\n[zz]\nq = 9\n[a.b]\nd = 2\n
   (out-of-order) now raises ParseError at parse time.

3. Dotted prefix (in-order) — [a]\nb.c=1\n[a.b]\nd=2\n now raises
   TOMLKitError at parse time.

Valid out-of-order tables (e.g. [a]\nx=1\n[zz]\n[a.b]\nc=1\n) continue
to parse and round-trip correctly.

Fixes #523